home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Gold Collection / Software Vault - The Gold Collection (American Databankers) (1993).ISO / cdr11 / adde13a.zip / ELTECREF.TXT < prev    next >
Text File  |  1993-06-26  |  42KB  |  848 lines
  1.  
  2.  
  3.  EchoList - The EchoMail Conference List                                Page 1
  4.  Technical Reference                                        as of: 21 Feb 1993
  5.  
  6.                        ================================
  7.                        The EchoList Technical Reference
  8.  
  9.                                   21 Feb 1993
  10.                        ================================
  11.  
  12.  
  13.  CONTENTS
  14.  
  15.  1.   PURPOSE.....................................................    2
  16.  2.   ECHOMAIL DISTRIBUTION BACKBONES.............................    2
  17.  3.   DEFINITIONS.................................................    3
  18.  4.   HOW IT WORKS................................................    3
  19.  5.   ECHOLIST CONTENTS...........................................    4
  20.  6.   RULES FILE REPOSITORY.......................................    4
  21.  7.   SPECIAL DATABASE FIELDS.....................................    5
  22.       7.1.   NODE ADDRESSES.......................................    5
  23.       7.2.   NAME FIELDS..........................................    5
  24.       7.3.   KEY FIELD............................................    5
  25.  8.   UPDATE MESSAGES.............................................    6
  26.       8.1.   TO ADD OR UPDATE AN ENTRY............................    7
  27.       8.2.   TO DELETE AN ENTRY...................................    7
  28.       8.3.   TO ADD OR UPDATE A CONFERENCE RULES FILE.............    8
  29.              8.3.1. Rules File Attach.............................    8
  30.              8.3.2. Rules File in Message Text....................    8
  31.  9.   MESSAGE FORMATTING DETAILS..................................    9
  32.  10.  UPDATE MESSAGE FIELD DESCRIPTIONS...........................    9
  33.  11.  PUBLICATION.................................................   13
  34.  12.  ADVANCED TECHNICAL ISSUES...................................   14
  35.       12.1.  DATABASE IMPLEMENTATION..............................   14
  36.       12.2.  KEY GENERATION.......................................   14
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  Copyright (c) 1993 by Michael G. Fuchs
  49.  
  50.  EchoList - The EchoMail Conference List                                Page 2
  51.  Technical Reference                                        as of: 21 Feb 1993
  52.  
  53.  1.   PURPOSE
  54.  
  55.  This document provides complete details on how to submit and maintain entries
  56.  in the EchoList.  For a quicker reference you can refer to the companion
  57.  Users Guide.  This Technical Reference is painfully long and boring.  But
  58.  that's the way it goes...
  59.  
  60.  The EchoList is a monthly publication which attempts to document certain
  61.  interesting information about EchoMail Conferences; "interesting" to people
  62.  who would like to participate, interesting to EchoMail Coordinators and those
  63.  who route the conference traffic, and potentially interesting to the
  64.  Conference Moderator.  The base product of the EchoList database is the
  65.  detailed Conference listing.  But, as needs are identified which can be
  66.  satisfied with the available information, additional reports and analyses can
  67.  be developed.
  68.  
  69.  Basically, the EchoList is maintained by the Moderators who choose to
  70.  advertise their conferences here.  Additions and updates to the database are
  71.  done by submitting NetMail messages addressed to a special name and node
  72.  address.  The Subject of the message indicates what is to be done, and the
  73.  body of the message has the data for the database entry, formatted as one
  74.  keyword and value per line.  If you're familiar with AREAFIX or RAID message
  75.  formatting, this will give you no trouble.
  76.  
  77.  Theoretically, updates should be sent by the conference Moderator.  A
  78.  password field is provided for the Moderator's use for controlling updates.
  79.  As far as I'm concerned, anybody who can help with additional information
  80.  (like seen-by's, paths...) is invited to do so.  And, if future automated
  81.  data gathering tools can be implemented, it will be encouraged.  Of course,
  82.  if the Moderator does not have the time to maintain the listing, a helpful
  83.  associate could do it.  Updates do not HAVE to be submitted by the Moderator,
  84.  they just have to identify one.
  85.  
  86.  I created and maintain the EchoList as an advertising service for Moderators,
  87.  and as a reference for users.  It is a completely open, international and
  88.  inter-network publication.  I do not generate, nor do I normally censor the
  89.  entries--they are the work of the Moderators.  In kind, I also take no
  90.  responsibility for the accuracy of any of the information in these entries.
  91.  I am in no position to pass judgment on the validity of EchoList entries.  It
  92.  is strictly a first come, first served database.
  93.  
  94.  A final note on adding entries to EchoList.  I will not list any conference
  95.  which promotes illegal activities.  Rejections based on unreasonableness will
  96.  be solely at my discretion.
  97.  
  98.  The EchoList was originated by Thomas Kenny, and the bulk of the original
  99.  design was initiated by Thomas, for which he has my thanks.
  100.  
  101.  2.   ECHOMAIL DISTRIBUTION BACKBONES
  102.  
  103.  A clarification is needed on the subject of EchoMail backbones and backbone
  104.  conferences.  The EchoList is not an official publication of any of the
  105.  
  106.  
  107.  Copyright (c) 1993 by Michael G. Fuchs
  108.  
  109.  EchoList - The EchoMail Conference List                                Page 3
  110.  Technical Reference                                        as of: 21 Feb 1993
  111.  
  112.  backbones, zones, networks or FidoNet.  It is an open, free directory of
  113.  information on ANY EchoMail conference, anywhere.
  114.  
  115.  However, a couple of distribution backbones have implemented a requirement
  116.  (which I heartily endorse) that any conference they carry must have a
  117.  Moderator identified.  The Zone 1 EchoMail Coordinator (among others) has
  118.  decided to use the EchoList as a convenient repository for official
  119.  information on backbone conferences.  So the only exception to the EchoList's
  120.  voluntary status is that dictated by the distribution backbone you may choose
  121.  to use.  If you are using one of these backbones you must list, at a minimum,
  122.  the Tag name, the Title, and the Moderators name and node number.
  123.  
  124.  I have no direct involvement in the distribution or administration of
  125.  EchoMail itself.  Any rules governing your conference need to be obtained
  126.  from your network and/or distribution backbone.
  127.  
  128.  3.   DEFINITIONS
  129.  
  130.  I used-to provide lengthy definitions of Moderators and Coordinators, since I
  131.  knew of no where else they were documented.  This is no longer the case,
  132.  since the backbones have published policy documents containing painstaking
  133.  detail.  I refer you to those documents.
  134.  
  135.  In the case of the EchoList, a Moderator is the person who defines a
  136.  Conference, and keeps it on track.  The Moderator may or may not be the
  137.  originator of the conference.  But he or she is assumed to be the one with
  138.  authority over the internal operation of the conference, with the right to
  139.  define it's purpose, policies and rules.  If a conference has no Moderator it
  140.  will not be listed in the EchoList.  If more than one Moderator is listed for
  141.  a conference entry in the EchoList, all are assumed equal in authority over
  142.  that database entry.
  143.  
  144.  If you know of a conference which you feel is important to the community and
  145.  it doesn't have a moderator I seriously suggest you consider taking on the
  146.  job.  How you do that, however, is business internal to the conference.
  147.  
  148.  4.   HOW IT WORKS
  149.  
  150.  If a Moderator wants to list a conference in the EchoList, he or she must
  151.  send a message in the proper format (as defined below) to the EchoList update
  152.  processor at 1:1/201.  Since this is a completely automated procedure, the
  153.  address name and node number must be exact in order to be picked-up.
  154.  
  155.  Update messages are processed at least once a day; I'm working on the
  156.  performance so that they can be processed after every NetMail call.  Every
  157.  properly addressed update message will generate a reply message back to you
  158.  via NetMail--even if the update failed.  In addition, adds and updates of
  159.  conference entries will be broadcast to interested EchoMail conferences
  160.  (unless you tell ELISTUPD not to).
  161.  
  162.  In order to provide a level of reliability to the list, EchoList entries
  163.  purge-off after six months.  If you want to keep your entry active, you
  164.  
  165.  Copyright (c) 1993 by Michael G. Fuchs
  166.  
  167.  EchoList - The EchoMail Conference List                                Page 4
  168.  Technical Reference                                        as of: 21 Feb 1993
  169.  
  170.  should re-send an update periodically (even if there are no changes) in order
  171.  to refresh the list.  The current purge criteria deletes EchoList entries
  172.  with a last-modified date older than six months.  The last-modified date is
  173.  the date the message was received and processed.  The EchoList is published
  174.  on a monthly basis (around the first of each month) and purging is not done
  175.  until the production date following the six-months anniversary.
  176.  
  177.  Updates to the EchoList are processed directly against the database, so there
  178.  is no advance cut-off date for inclusion in a given edition.  BUT, the
  179.  EchoList is currently maintained as part of a hobby, so other time
  180.  constraints will dictate how much can actually be accommodated in a given
  181.  month and what the actual production date will be.  It could be anywhere from
  182.  the 25th through the 5th.  I can only suggest that important changes be sent
  183.  early in the month.
  184.  
  185.  5.   ECHOLIST CONTENTS
  186.  
  187.  The EchoList is maintained in an object-oriented database, which improves
  188.  data management and reporting, and provides a great deal of flexibility
  189.  concerning the contents of the database.  But the update messages are
  190.  processed by an automated front-end program which edits and processes them;
  191.  and it is quite unforgiving.  Computer programs are very literal cretins.
  192.  
  193.  The minimum information required for an EchoList entry includes: The symbolic
  194.  area Tag name used by the conference, a Title or brief descriptive phrase for
  195.  the conference, and at least one Moderator's name and node number.
  196.  
  197.  I understand that, for security reasons, certain Moderators do not want to
  198.  publicize the Tag name in order to control unauthorized links to a private
  199.  conference.  The EchoList has the ability to suppress the display of the Tag
  200.  name in the EchoList reports.  However, the Tag name is the key to the
  201.  database and all update processes.  So even if you want it unpublished, it
  202.  must be provided.
  203.  
  204.  In addition to the Tag name, the EchoList implements a derived Key field for
  205.  each conference.  You can ignore the existence of this internal Key in all
  206.  but the most unusual situations.  It is used to provide a unique, DOS file
  207.  name compatible abbreviation of the Tag, and to allow multiple conferences
  208.  with the same Tag (perhaps in different networks) to maintain independent
  209.  EchoList entries.  For those interested, there is a section devoted to the
  210.  topic later in this document.
  211.  
  212.  If you feel there is a piece of information that is missing from this
  213.  database but vital, please bring it to my attention.
  214.  
  215.  The best way to explain the various fields in the EchoList is to describe the
  216.  format for submitting additions and updates.  You'll find that in section 7.
  217.  
  218.  6.   RULES FILE REPOSITORY
  219.  
  220.  In addition to the EchoList itself, I provide a repository for text files
  221.  documenting the rules for individual conferences.  The rules files are
  222.  
  223.  Copyright (c) 1993 by Michael G. Fuchs
  224.  
  225.  EchoList - The EchoMail Conference List                                Page 5
  226.  Technical Reference                                        as of: 21 Feb 1993
  227.  
  228.  tracked in the database, but are not reported as part of the EchoList.  They
  229.  are stored in a separate compressed file.  Rules files have no purge criteria
  230.  and do not have to be refreshed unless you change them.  They will be valid
  231.  as long as there is an EchoList entry for that conference.
  232.  
  233.  7.   SPECIAL DATABASE FIELDS
  234.  
  235.  7.1.    NODE ADDRESSES
  236.  The EchoList has a number of fields that provide storage of Node Addresses.
  237.  The EchoList supports "5-D" or "Domain" addressing throughout--with a twist.
  238.  
  239.  All places in the EchoList where you can use a node address, support the full
  240.  notation:
  241.            zzz:ttt/nnn.ppp@ddddddd
  242.  
  243.  where zzz is the zone number, ttt is the net, nnn is the node, ppp is the
  244.  point (if applicable), and ddd is the Domain.  Zone, net, node and point are
  245.  each integer fields.  Domain is a text field than cannot contain spaces.
  246.  Other than that, the Domain can contain anything you need.
  247.  
  248.  The twist is that the EchoList allows use of the Domain field by itself to
  249.  specify non-FidoNet addresses.  Lets say, for example, you wanted to list
  250.  your Compuserve user id as an alternate address, you could enter:
  251.  
  252.            MOD  Mike Fuchs, 1:266/71@fidonet.org
  253.            MOD  Mike Fuchs, @CIS-72760.3326
  254.  
  255.  But who'd want to do that...  Ah well, it's a Lucky Strike extra I threw in
  256.  to the NODE_ADDRESS processing routines.
  257.  
  258.  7.2.    NAME FIELDS
  259.  
  260.  In order to accommodate the wide variety of ways people want their name to
  261.  appear, I've devised a really strange way of parsing names in incoming
  262.  messages.  In order to sort names by last name, I need to store the first
  263.  name and last name separately.
  264.  
  265.  The line is parsed into tokens--words separated by spaces, tabs or commas.
  266.  When I expect a name and address, the last token (word) is looked-at to see
  267.  if it's a node address.  If it is, fine.  If it isn't, it defaults to the
  268.  address of the sender of the message.  From there, at least the last token is
  269.  taken as the last name--even if it means there's no first name.  I work my
  270.  way backwards through the stack of tokens.  I add each token to the beginning
  271.  of the last name field until I hit the first token or hit a token that ends
  272.  in a period (which is assumed to be a middle initial).  The first name and
  273.  middle initial (if present) are put in the first name field.  Aren't you
  274.  sorry you asked?
  275.  
  276.  7.3.    KEY FIELD
  277.  
  278.  The primary index into the EchoList database is the Tag name.  Starting with
  279.  version 2 the EchoList also maintains an index field called the area KEY.
  280.  
  281.  
  282.  Copyright (c) 1993 by Michael G. Fuchs
  283.  
  284.  EchoList - The EchoMail Conference List                                Page 6
  285.  Technical Reference                                        as of: 21 Feb 1993
  286.  
  287.  For the sake of standardizing definitions:  "Tags" are the symbolic mnemonics
  288.  used by conference distribution software.  They are also referred to as Area
  289.  names, Group names or Tag names.
  290.  
  291.  "Keys" are one-to-eight character alphanumeric codes, unique for each
  292.  EchoList entry.  They are generated automatically by the EchoList system
  293.  based on the area Tag name you use.  They are intended to be compatible with
  294.  all operating system file name conventions (MS-DOS being the least common
  295.  denominator).  They are no more than eight characters, include only
  296.  alphabetic and numeric characters, and are guaranteed to be unique within all
  297.  EchoList entries.
  298.  
  299.  99% of you can ignore the existence of these keys.  The Tags are still used
  300.  for identification as before.  The Keys are an addition.  Using another index
  301.  as the unique key will allow multiple EchoList entries using the same Tag.
  302.  The update program will allow inserting multiple entries for the same Tag by
  303.  manually specifying unique Keys.
  304.  
  305.  Another use of the Key field is to generate unique file names for the rules
  306.  files.  This eliminates the chance of two moderators accidentally using the
  307.  same names.  It also allows accepting Rules File text in NetMail messages,
  308.  with ELISTUPD creating the .RUL file here (rather than having to send file-
  309.  attaches).
  310.  
  311.  If you want to manually specify a Key, it must follow the same rules as the
  312.  automatically generated ones.  Namely:  It must be unique within the EchoList
  313.  database, it must be from one to eight characters, and it must only contain
  314.  alphabetic and numeric characters.  If specified, the KEY line must
  315.  immediately follow the TAG line.
  316.  
  317.  8.   UPDATE MESSAGES
  318.  
  319.  EchoList updates must be formatted and transmitted in a NetMail message as
  320.  explained below.  The update process is completely automated, which requires
  321.  strict adherence to this format.
  322.  
  323.  I would suggest using a message generator such as TELL or ROBOT against a
  324.  text file to generate the Conference update message.  But, please DO NOT SHIP
  325.  IT AS A FILE ATTACH!  The information must be in the body of a message.
  326.  
  327.  To add or update an EchoList entry, submit a NetMail message to "ECHOLIST" at
  328.  1:1/201.  The message subject is the type of processing to be done, usually
  329.  "MOD UPD".  The body of the message text has the data for the database entry,
  330.  formatted so that every line starts with a special keyword that identifies
  331.  the field name, followed by the data to be put in that field.  Most of the
  332.  lines are optional.  If you don't want to supply data for a given field,
  333.  don't include it in the message at all.  The only required fields are TAG,
  334.  TITLE and MODERATOR.
  335.  
  336.  The first line describing a conference entry is TAG.  The other lines can
  337.  come in any order, but TAG must come first.  The CAPITALIZED part of the
  338.  keyword is the minimum abbreviation you can use.  The To-name, subject,
  339.  keywords and passwords are NOT case sensitive.
  340.  
  341.  Copyright (c) 1993 by Michael G. Fuchs
  342.  
  343.  EchoList - The EchoMail Conference List                                Page 7
  344.  Technical Reference                                        as of: 21 Feb 1993
  345.  
  346.  The EchoList update processor is run daily.  All submissions will generate a
  347.  reply message whose subject will explain that the entry was: "Accepted",
  348.  "Accepted with Warnings", or "Rejected for Errors".  Acceptance messages will
  349.  also specify the Edition in which the update will appear.  The text body will
  350.  provide detailed, line-by-line edit messages, and it may also include
  351.  standard epilog text appended to all reply messages as a sort of bulletin
  352.  facility from me to the moderators.
  353.  
  354.            Syntax used below:  CAPITALS are used to indicate the
  355.            minimum abbreviation of reserved-word literals--you don't
  356.            have to capitalize anything.  Upper/lower case for
  357.            passwords and keywords is irrelevant.  <...> is used to
  358.            indicate a value to be supplied by the submitter.
  359.  
  360.  There are three formats for Moderators to use;  two for EchoList Entries and
  361.  one for Rule File submission.
  362.  
  363.  8.1.    TO ADD OR UPDATE AN ENTRY
  364.  
  365.  To:       ECHOLIST
  366.  At:       1:1/201
  367.  Subject:  MODerator UPDate
  368.  
  369.  In the body of the message:
  370.  
  371.      TAGname       <symbolic area name> /NOSHow
  372.      TITLe         <brief area title for sorting>
  373.      DESCription   <A full description of the conference, audience, topics...>
  374.      MODerator     <moderator name>, <moderator node>
  375.      PASSword      <current password>, <new password>
  376.      TOTalnodes    <number of nodes carrying this conference>
  377.      VOLume        <number of messages>/<Month or Day or Week>
  378.      RESTrictions  /SYSop /MOD-apvl /MEMber
  379.      ORIGin        <origination node of the distribution
  380.      DISTribution  <distribution areas or vehicles of note>
  381.      GATEway       <gateways to other zones & networks crossed by the
  382.                    conference>
  383.      SEENby        <node list>
  384.      PATH          <node-pair list>
  385.      ---
  386.  
  387.  I've left off the KEY field to avoid confusion.  If you want to override the
  388.  automatic key generation, read the docs on the KEY line.  If used, the KEY
  389.  line must come immediately after the TAG line.
  390.  
  391.  8.2.    TO DELETE AN ENTRY
  392.  
  393.  This also deletes its Rule File if it exists.
  394.  
  395.  To:       ECHOLIST
  396.  At:       1:1/201
  397.  Subject:  MODerator DELete
  398.  
  399.  
  400.  Copyright (c) 1993 by Michael G. Fuchs
  401.  
  402.  EchoList - The EchoMail Conference List                                Page 8
  403.  Technical Reference                                        as of: 21 Feb 1993
  404.  
  405.  In the body of the message:
  406.  
  407.      TAGname       <symbolic area name>
  408.      PASSword      <current password>
  409.      ---
  410.  
  411.  8.3.    TO ADD OR UPDATE A CONFERENCE RULES FILE
  412.  
  413.  8.3.1.    Rules File Attach
  414.  In order to submit a Rules File the EchoList entry must already have been
  415.  added with a MOD UPD message.  Rules File messages can be used only for that-
  416.  -adding Rules Files to entries that are already in the database.
  417.  
  418.  There are two ways to submit a rules file.  The first way is to create a text
  419.  file containing your rules and policies, and send it via NetMail as a file-
  420.  attach.  The subject of a file attach message is obviously the name of the
  421.  file, and the file-attach bit must be on in the message header.  The message
  422.  body text must specify the Tag name and password to link the rules file to.
  423.  
  424.  To:       ECHOLIST        (as a File Attach message)
  425.  At:       1:1/201
  426.  Subject:  <attached rules file name (xxxxxxxx.RUL)>
  427.  
  428.  In the body of the message:
  429.  
  430.      TAGname       <symbolic area name>
  431.      PASSword      <current password>
  432.      ---
  433.  
  434.  8.3.2.    Rules File in Message Text
  435.  The second way of submitting a rules file is to imbed it in the text of a
  436.  NetMail message.  This can allow for routing the rules file through
  437.  intermediate systems.  The Rules File text starts with the first line
  438.  FOLLOWING the RULETEXT keyword line, and ends at the "---" tear line.  During
  439.  processing here, all those lines, word-wrapped at 80 characters, are written
  440.  to a file named for your entry's Key.
  441.  
  442.  To:       ECHOLIST        (as a File Attach message)
  443.  At:       1:1/201
  444.  Subject:  MODerator RULes
  445.  
  446.  In the body of the message:
  447.  
  448.      TAGname       <symbolic area name>
  449.      PASSword      <current password>
  450.      RULEtext
  451.      <rule file text ...>
  452.      < . . . >
  453.      ---
  454.  
  455.            * Note you MUST use a --- tear line in ALL of these
  456.            messages after the update info and before any trailing
  457.            "signature" or message text.
  458.  
  459.  Copyright (c) 1993 by Michael G. Fuchs
  460.  
  461.  EchoList - The EchoMail Conference List                                Page 9
  462.  Technical Reference                                        as of: 21 Feb 1993
  463.  
  464.  
  465.  9.   MESSAGE FORMATTING DETAILS
  466.  
  467.  Each keyword MUST begin on a new line.  Lines MUST end with a 'hard' return.
  468.  Most keywords allow multiple lines to be used for fields that don't fit on
  469.  one line.  When multiple lines of data are provided for a single keyword,
  470.  every line MUST be preceded by the keyword.
  471.  
  472.  The first keyword line must be the area Tag name.  The order of the rest of
  473.  the lines is unimportant, but it is suggested that the MODerator line be
  474.  entered before any SEENby and PATH lines.  If more than one conference is
  475.  being listed in a single message, separate the lines for one conference from
  476.  the other with at least one blank line.
  477.  
  478.  An update that is missing some keyword line(s) results in no change to the
  479.  fields of an existing EchoList entry affected by the missing keyword(s).  If
  480.  you want to delete a field such that a keyword's database field is null (like
  481.  dropping all Restrictions) supply the keyword on a line by itself with no
  482.  arguments.
  483.  
  484.  Keyword lines generally replace the associated field(s) in the database in
  485.  their entirety.  The exceptions are MODERATOR, PATH and SEENBY.  Normally,
  486.  the node list for PATH and SEENBY simply replaces the entire list in the
  487.  database.  But, if you want to modify the list that's already there, you can
  488.  prefix the keyword with a plus (+).  The "+" will cause the list to be added
  489.  to the existing database (duplicates are ignored).  Likewise with MODerator
  490.  lines, if ANY are in an update, the entire list of Moderators is replaced in
  491.  the database.  If (at least the first) MOD keyword is prefixed with a "+",
  492.  all the MOD lines will be added to the database record.
  493.  
  494.  If the message subject is MODerator DELete, only the Tag name field and
  495.  Password (if set) are used.  The Conference will be dropped from the list,
  496.  and the Rules File (if it exists) will be deleted.
  497.  
  498.  For Rules File updates, only the Tag name field and Password (if set) are
  499.  used.  The rules file name will be forced to the conference Key to make sure
  500.  it doesn't duplicate someone else's file name.
  501.  
  502.  10.  UPDATE MESSAGE FIELD DESCRIPTIONS
  503.  
  504.  The following is a description of each field.  The part of the keyword that
  505.  is capitalized is the minimum required.  The actual case of the keywords you
  506.  use is irrelevant.  Brackets ([]) denote optional arguments -- do not include
  507.  the brackets in your message.  Text character counts are recommended
  508.  maximums.  In reality, all text fields are variable length, and the only
  509.  limitation is overall record size and my opinion of what is reasonable.
  510.  
  511.  A * means the line is optional.
  512.  A + means the line can be repeated multiple times.
  513.  
  514.  
  515.  
  516.  Copyright (c) 1993 by Michael G. Fuchs
  517.  
  518.  EchoList - The EchoMail Conference List                               Page 10
  519.  Technical Reference                                        as of: 21 Feb 1993
  520.  
  521.                    MINIMUM
  522.  KEYWORD     *+    ABBREVIATION    ARGUMENTS
  523.  TAGname           TAG <areaname> [/NO]
  524.                    The "area name" used for distributing the conference.  If
  525.                    the moderator does not want to make the area name public,
  526.                    you can add the parameter "/NOSHOW" (with at least one
  527.                    intervening blank or tab) after the area name.
  528.  
  529.  PASSword          PASS <currentpwd>[, <newpwd>]
  530.                    The current password field is only required if one has been
  531.                    set.  If set, the current password must match in order to
  532.                    do a Moderator Update or Delete or Rules File.  To change
  533.                    the password at any time, simply provide the current
  534.                    password, a comma, and the new password.  An initial
  535.                    password is set by leaving the current password field blank
  536.                    and starting with the comma.  Case is ignored.  There is no
  537.                    facility for removing a password (changing it to null).
  538.                    [Text 12 chars]
  539.  
  540.  MODerator    +    MOD <firstname> <lastname(s)>, <node>
  541.                    The name and net address of the moderator, separated by a
  542.                    comma.  ONLY ONE MODERATOR AND ADDRESS CAN BE LISTED PER
  543.                    LINE.  If multiple Moderators need to be listed, they will
  544.                    be reported in the same order submitted.  Do not use middle
  545.                    names.  If you use a middle initial, make sure it has a
  546.                    period.  Node numbers in this field and throughout the
  547.                    database are stored as four integers plus a text Domain.
  548.                    They are input and displayed as
  549.                    <zone>:<net>/<node>.<point>@<domain> .  The 'point' is
  550.                    (obviously) optional, and if the zone is not specified, the
  551.                    zone of the message sender is used.  If no zone is found
  552.                    (@INTL address), the zone defaults to the zone of the
  553.                    EchoList processor.  If the domain is omitted, but the zone
  554.                    matches either the sender or the EchoList processor
  555.                    address, that Domain text is used.  If there is still no
  556.                    Domain, the EchoList has a list of zone-domain pairs to use
  557.                    as a guess.  If anyone can provide me with a more complete
  558.                    list, please send it!
  559.  
  560.  TITLe             TITL <short conference title>
  561.                    A SORT-ABLE title for the conference. (avoid starting with
  562.                    things like A, An, The...)
  563.                    [Text 70 chars]
  564.  
  565.  DESCription  +    DESC <longer description>
  566.                    Describe the conference. The topics, audience, policies,
  567.                    and anything else that would be helpful.  Don't bother
  568.                    trying fancy formatting.  All the lines are combined and
  569.                    word-wrapped into a single paragraph.
  570.  
  571.  The following three lines, ORIGIN, DISTRIBUTION and GATEWAY are really just
  572.  an organized set of free text fields you can use to describe sources and
  573.  contacts that control links to the conference.  Use none, any or all of them
  574.  as you see fit.  If you are on a formal distribution backbone of some kind,
  575.  
  576.  Copyright (c) 1993 by Michael G. Fuchs
  577.  
  578.  EchoList - The EchoMail Conference List                               Page 11
  579.  Technical Reference                                        as of: 21 Feb 1993
  580.  
  581.  don't just say BACKBONE--there are lots of them.  Specifically say "Zone 1
  582.  Backbone" or "Zone-3 Backbone" or "EchoNet Backbone", etc.
  583.  
  584.  ORIGin       *+   ORIG <originator node text>
  585.                    If appropriate, describe the originator node of the
  586.                    conference.
  587.                    [Text 70 chars]
  588.  
  589.  DISTribution *+   DIST <distr1>[, <distr2>, ... <distrN>]
  590.                    If appropriate, describe the extent and/or manner in which
  591.                    the conference is distributed, and/or limited.  Multiple
  592.                    keywords separated by commas and/or spaces are fine.  Valid
  593.                    regional descriptors would be: Z1-BACKBONE, ALTERNET, ZONE-
  594.                    1, REGION-13, NET-105, LOCAL-CHICAGO, etc.  Restrictive
  595.                    values would be: NET-107-ONLY, CHICAGO-ONLY.  If topology
  596.                    is strict, distribution node(s) can be listed as:
  597.                    1:123/789.  No descriptive text, please.  This field is
  598.                    manually edited by me to some degree for consistency and
  599.                    reasonableness.  When and if I think I've got a complete
  600.                    enough list, I'll implement automatic checking.
  601.                    [Text 70 chars]
  602.  
  603.  GATEway      *+   GATE <gate1> VIA <gate2>[, <gate3> VIA <gate4>, ...]
  604.                    If the conference is transmitted via gateways to other
  605.                    zones or networks, use this field to specify those links.
  606.                    Each gateway must be a pair of expressions separated by the
  607.                    word "via".  Each expression can be either a node number or
  608.                    an environment name.  If multiple gateways are listed,
  609.                    separate them with commas.  e.g.:  UseNet via 999/111,
  610.                    Zone-3 via 1:200/999, 2:100/200 via 3:200/100.
  611.                    [Text 70 chars]
  612.  
  613.  TOTalnodes   *    TOT <numnodes>
  614.                    This is an estimate of the total number of nodes that are
  615.                    active in the conference.  It is NOT a descriptive text
  616.                    field.  It's optional.  If supplied, save the editorials--
  617.                    it's just a single integer number.
  618.  
  619.  VOLume       *    VOL <num>/M  or  VOL <num>/W  or  VOL <num>/D
  620.                    This is an estimate of the number of messages entered in a
  621.                    given period of time for the benefit of those planning to
  622.                    link-in.  Enter it as a NUMBER followed by a SLASH followed
  623.                    by the word MONTH, WEEK, or DAY.
  624.  
  625.  RESTrictions *    REST [/SYS] [/MOD] [/MEM]
  626.                    This line can contain one or more restriction identifiers.
  627.                    It's a shorthand reference to certain Moderator-imposed
  628.                    rules.  Enter /SYSOP if the conference is restricted to
  629.                    Sysops only.  Enter /MOD-APVL if Moderator approval is
  630.                    required prior to linking in.  Enter /MEMBER if
  631.                    participants must be validated members of some group or
  632.                    organization (e.g.: MENSA-ONLY).  Note that these are not
  633.                    any-old text string you want to call a restriction.  These
  634.                    actually set individual, pre-defined, binary flags in the
  635.  
  636.  Copyright (c) 1993 by Michael G. Fuchs
  637.  
  638.  EchoList - The EchoMail Conference List                               Page 12
  639.  Technical Reference                                        as of: 21 Feb 1993
  640.  
  641.                    EchoList database.  If there are other generic flags you
  642.                    think should be added, let me know.
  643.  
  644.  SEENby       *+   SEEN <node> [<node> <node> ... <node>]
  645.                    This is a list of nodes that get the conference.  This is
  646.                    probably a total waste of space if you're documented as
  647.                    being distributed on one of the backbones.  You can enter
  648.                    them in any order, and can simplify them the way real SEEN-
  649.                    BY lines are in messages (dropping the zone & net when
  650.                    they're the same as the previous node).  If the domain,
  651.                    zone and/or net are missing from the first node, they are
  652.                    carried from the moderator address;  if that's missing,
  653.                    from the sender's address.  They are also carried forward
  654.                    from one line to the next if needed.  The EchoList will
  655.                    automatically simplify them, eliminate duplicates, and sort
  656.                    them.  The bottom line is, you can pull these lines
  657.                    straight from messages if you like.  If you don't know (or
  658.                    care about) the nodes, but know nets, or there are too many
  659.                    to list at the node level, drop the node number, such:
  660.                    "1:107/".
  661.  
  662.  +SEENby      *+   This is exactly the same as SEEN above, except that the
  663.                    list of nodes is added to the list already in the database.
  664.  
  665.  PATH         *+   PATH <node> [<node> <node> ... <node>]
  666.                    or PATH <node><><node>[, <node><><node>, ...]
  667.                    There are two ways to provide this data.  Internally to the
  668.                    EchoList database, the path connections are stored as
  669.                    unordered pairs of nodes.  So the method of input does not
  670.                    affect storage in the database.  The simplest method of
  671.                    input is to have one line for each valid node path (like
  672.                    the PATH lines added by certain mailers/scanners).
  673.                    Formatting would look like the SEENby line, but the order
  674.                    will indicate the actual path taken by a message, and
  675.                    individual lines will not be concatenated but be treated as
  676.                    different paths.  Duplicate segments will automatically be
  677.                    eliminated during database processing, so you can use
  678.                    multiple, overlapping PATH lines from messages as the basis
  679.                    for this.  One warning, however: long PATHs in real echo
  680.                    messages get "wrapped" with follow-on lines starting with
  681.                    PATH.  This is not correct for the EchoList.  Either turn
  682.                    such wrapped lines from an individual message into one long
  683.                    line, or repeat the last node number from the previous line
  684.                    at the beginning of the next line to show that link.
  685.  
  686.                    Alternatively, you can provide the input in the same format
  687.                    that EchoList outputs it: as pairs of linked node numbers
  688.                    connected by the "<>" characters.  Regardless of the format
  689.                    used, please edit-in the zone numbers and domains where
  690.                    appropriate.  Both input formats 'inherit' domain, zone and
  691.                    net numbers from previous entries in the same way as SEENby
  692.                    lines.
  693.  
  694.  
  695.  Copyright (c) 1993 by Michael G. Fuchs
  696.  
  697.  EchoList - The EchoMail Conference List                               Page 13
  698.  Technical Reference                                        as of: 21 Feb 1993
  699.  
  700.  +PATH        *+   This is exactly the same as PATH above, except that the
  701.                    list of node pairs is added to the list already in the
  702.                    database.
  703.  
  704.  There are a few fields that you cannot set directly, but are retained in the
  705.  EchoList database.
  706.  
  707.  rule file name    This is not a keyword provided field.  If a rule file
  708.                    update is sent-in, the file name is stored with the
  709.                    database entry.
  710.  
  711.  date added        The date the entry was originally added.
  712.  
  713.  last modified     The date and sender of the last update message successfully
  714.                    processed.
  715.  
  716.  11.  PUBLICATION
  717.  
  718.  The EchoList is published on or about the first of each month.  The monthly
  719.  release is sent to Regional Software Dist nodes who want it (1/3xx).  There
  720.  is no guarantee that they will make it available for download or file-
  721.  request, or pass it across zones unless you ask them.
  722.  
  723.  The latest version (which may include interim updates during a month) will
  724.  always be available for file-request from 1:1/201 via the "magic" file name:
  725.  "ECHOLIST" (no period or extension).  The actual file name you get will be
  726.  ELISTnnn.LZH, where nnn is the edition identifier.  It will contain, at a
  727.  minimum, the file ELISTnnn.TXT, the detailed EchoList report sorted by
  728.  conference title.
  729.  
  730.  The combined rules files can be requested as "ECHORULE", which will provide a
  731.  file named ELRULnnn.LZH.
  732.  
  733.  These instructions will be updated from time-to-time, and are available for
  734.  file-request via the "magic" file name: "ECHOMOD".  Which delivers the file
  735.  ELMODmyy.LZH.
  736.  
  737.  The EchoList, it's derivative reference files, and these instructions, are
  738.  all Copyright (c) Michael G. Fuchs 1988-93, and all rights are reserved.  All
  739.  files may be freely copied and distributed provided no charge is made for
  740.  such copying and distribution, and no changes whatsoever are made to the
  741.  files or their contents.
  742.  
  743.  Comments, questions and suggestions should be sent to me, Mike Fuchs, at
  744.  1:1/201, and are heartily encouraged.  Thank you for your patience with these
  745.  long-winded instructions.
  746.  
  747.  
  748.  
  749.  
  750.  Copyright (c) 1993 by Michael G. Fuchs
  751.  
  752.  EchoList - The EchoMail Conference List                               Page 14
  753.  Technical Reference                                        as of: 21 Feb 1993
  754.  
  755.  12.  ADVANCED TECHNICAL ISSUES
  756.  
  757.  This is really absurdly detailed information that nobody should have to be
  758.  concerned with.  But, for those of you who are interested, here it is.
  759.  
  760.  12.1.   DATABASE IMPLEMENTATION
  761.  
  762.  The EchoList system was completely rewritten from the ground-up for version
  763.  2.  It is implemented in C++, and utilizes an Object Oriented database class
  764.  of my own.  When It's "done" I will consider making the system available as a
  765.  package to those who want to maintain a private EchoList.  When it's
  766.  available, I'll publicize it.
  767.  
  768.  The text fields in the database are variable length strings.  Their length is
  769.  not arbitrarily limited, however you can be assured I'd edit-down any text
  770.  submitted that was really excessive.
  771.  
  772.  Seen-by node-addresses and Path node-address pairs are stored in Sets
  773.  separate from the base EchoArea table, so the number of entries per area is
  774.  unlimited.  This, coupled with storage of node numbers in four integer fields
  775.  plus a text field each, provides the maximum flexibility in reporting and
  776.  analysis (like path analysis that'll get done some day).
  777.  
  778.  I have discovered a bewildering range of differences in message files sent
  779.  from various editors.  They all seem to have their own little quirks.  If you
  780.  know of any message editor that cannot generate a hard return under user
  781.  control, please let me know with a sample message.
  782.  
  783.  12.2.   KEY GENERATION
  784.  
  785.  Beyond the internal uses for duplicate Tags and Rules File naming, interest
  786.  was expressed in having a standardized source for filenames unique to each
  787.  conference.  I don't know whether anybody will use them, but the list of Keys
  788.  are available in a couple of table files, as well as in the distributed data-
  789.  file version of the EchoList.  I'll also publish the algorithm, but because
  790.  of the collision detection logic you can't be sure you're generating exactly
  791.  the same Key as the EchoList.  For what it's worth, I'm supplying them.  If
  792.  anybody has a use for them, let me know.
  793.  
  794.  How does the Key get generated?  You shouldn't need to care.  And I can't
  795.  take credit for the algorithm, as much of it was suggested by others.  But if
  796.  you're curious...
  797.  
  798.  First, the Tag has all non-alphanumeric characters removed.  If the result is
  799.  eight characters or less, we're done.
  800.  
  801.  Next, any vowels beyond the first character are removed.  (The first
  802.  character is never dropped.)
  803.  
  804.  If it's still longer than eight characters, then we drop every fourth
  805.  character.
  806.  
  807.  If all this hasn't gotten it <= 8 characters, truncate it to eight and we are
  808.  done.
  809.  
  810.  Copyright (c) 1993 by Michael G. Fuchs
  811.  
  812.  EchoList - The EchoMail Conference List                               Page 15
  813.  Technical Reference                                        as of: 21 Feb 1993
  814.  
  815.  Now the Key is checked for collision with existing Keys for other Area Tags.
  816.  
  817.  If it collides, it has '0's appended one-by-one until doesn't collide.  If
  818.  it's already eight chars, the last character is replaced with a '0'.
  819.  
  820.  If it continues to collide, the code starts incrementing the trailing numbers
  821.  until it doesn't.
  822.  
  823.  Anybody got a better idea, let me know.
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  Copyright (c) 1993 by Michael G. Fuchs
  848.